目录

字符设备驱动简介

驱动模块的加载和卸载

字符设备注册与注销

实现设备的具体操作函数

添加LICENSE和作者信息

Linux设备号的组成

设备号的分配

chrdevbase字符设备驱动开发实验

创建VSCode工程

添加头文件路径

编写实验程序

C库文件操作基本函数

编写测试APP 程序

编译驱动程序

编译测试APP

加载驱动模块

创建设备节点文件

chrdevbase设备操作测试

卸载驱动模块

字符设备是Linux驱动中最基本的一类设备驱动,字符设备就是一个一个字节,按照字节流进行读写操作的设备,读写数据是分先后顺序的。比如我们最常见的点灯、按键、IIC、SPI,LCD等等都是字符设备,这些设备的驱动就叫做字符设备驱动。

在详细的学习字符设备驱动架构之前,我们先来简单的了解一下Linux下的应用程序是如何调用驱动程序的,Linux应用程序对驱动程序的调用如图所示:

 在Linux中一切皆为文件,驱动加载成功以后会在"/dev”目录下生成一个相应的文件,应用程序通过对这个名为"/dev/xxx”(xxx是具体的驱动文件名字)的文件进行相应的操作即可实现对硬件的操作。比如现在有个叫做/dev/led的驱动文件,此文件是led灯的驱动文件。应用程序使用open函数来打开文件/dev/led,使用完成以后使用close函数关闭/dev/led这个文件。open和close就是打开和关闭led驱动的函数,如果要点亮或关闭led,那么就使用write函数来操作,也就是向此驱动写入数据,这个数据就是要关闭还是要打开led的控制参数。如果要获取led 灯的状态,就用read函数从驱动中读取相应的状态。

应用程序运行在用户空间,而Linux驱动属于内核的一部分,因此驱动运行于内核空间。当我们在用户空间想要实现对内核的操作,比如使用open函数打开/dev/led 这个驱动,因为用户空间不能直接对内核进行操作,因此必须使用一个叫做“系统调用”的方法来实现从用户空间“陷入”到内核空间,这样才能实现对底层驱动的操作。open、close、write和read等这些函数是由 C 库提供的,在 Linux系统中,系统调用作为C 库的一部分。当我们调用open 函数的时候流程如图所示:

 其中关于C库以及如何通过系统调用“陷入”到内核空间这个我们不用去管,我们重点关注的是应用程序和具体的驱动,应用程序使用到的函数在具体驱动程序中都有与之对应的函数,比如应用程序中调用了open这个函数,那么在驱动程序中也得有一个名为open的函数。每一个系统调用,在驱动中都有与之对应的一个驱动函数,在Linux内核文件include/linux/fs.h中有个叫做file_operations的结构体,此结构体就是Linux内核驱动操作函数集合,内容如下所示:

 第1589行,owner拥有该结构体的模块的指针,一般设置为THIS_MODULE。

第1590行,llseek 函数用于修改文件当前的读写位置。

第1591行, read函数用于读取设备文件。

第1592行, write函数用于向设备文件写入(发送)数据。

第1596行,poll是个轮询函数,用于查询设备是否可以进行非阻塞的读写。

第1597行, unlocked_ioctl函数提供对于设备的控制功能,与应用程序中的ioctl函数对应。

第1598行, compat_ioctl函数与unlocked_ioctl函数功能一样,区别在于在64位系统上,32位的应用程序调用将会使用此函数。在32位的系统上运行32位的应用程序调用的是unlocked_ioctl。

第1599行, mmap函数用于将设备的内存映射到进程空间中(也就是用户空间),一般帧缓冲设备会使用此函数,比如LCD驱动的显存,将帧缓冲(LCD显存)映射到用户空间中以后应用程序就可以直接操作显存了,这样就不用在用户空间和内核空间之间来回复制。

第1601行,open函数用于打开设备文件。

第1603行, release函数用于释放(关闭)设备文件,与应用程序中的close函数对应。

第1604行, fasync函数用于刷新待处理的数据,用于将缓冲区中的数据刷新到磁盘中。

第1605行, aio_fsyne函数与fasyne函数的功能类似,只是aio_fsync是异步刷新待处理 的的数据。

在字符设备驱动开发中最常用的就是上面这些函数,关于其他的函数大家可以查阅相关文档。我们在字符设备驱动开发中最主要的工作就是实现上面这些函数,不一定全部都要实现,但是像open, release, write、read等都是需要实现的,当然了,具体需要实现哪些函数还是要看具体的驱动要求。

Linux驱动有两种运行方式,第一种就是将驱动编译进Linux内核中,这样当Linux内核启动的时候就会自动运行驱动程序。第二种就是将驱动编译成模块(Linux下模块扩展名为.ko),在Linux内核启动以后使用"insmod”命令加载驱动模块。在调试驱动的时候一般都选择将其编译为模块,这样我们修改驱动以后只需要编译一下驱动代码即可,不需要编译整个Linux代码。而且在调试的时候只需要加载或者卸载驱动模块即可,不需要重启整个系统。总之,将驱动编译为模块最大的好处就是方便开发,当驱动开发完成,确定没有问题以后就可以将驱动编译进Linux内核中,当然也可以不编译进Linux内核中,具体看自己的需求。模块有加载和卸载两种操作,我们在编写驱动的时候需要注册这两种操作函数,模块的加载和卸载注册函数如下:

 module_init函数用来向Linux内核注册一个模块加载函数,参数xxx_init就是需要注册的具体函数,当使用“insmod”命令加载驱动的时候,xxx_init这个函数就会被调用。module_exit()函数用来向Linux内核注册一个模块卸载函数,参数xxx_exit就是需要注册的具体函数,当使用“rmmod”命令卸载具体驱动的时候xxx_exit 函数就会被调用。字符设备驱动模块加载和卸载模板如下所示:

 第2行,定义了个名为 xxx init 的驱动入口函数,并且使用了“_init”来修饰。

第9行,定义了个名为xxx_exit的驱动出口函数,并且使用了“exit”来修饰。

第15行,调用函数module_init来声明xxx_init为驱动入口函数,当加载驱动的时候xxx_init函数就会被调用。

第16行,调用函数module_exit来声明xxx_exit为驱动出口函数,当卸载驱动的时候xxx_exit函数就会被调用。

驱动编译完成以后扩展名为.ko,有两种命令可以加载驱动模块:insmod和modprobe， insmod是最简单的模块加载命令,此命令用于加载指定的.ko模块,比如加载drv.ko这个驱动模块,命令如下:

 insmod命令不能解决模块的依赖关系,比如drv.ko依赖first.ko这个模块,就必须先使用insmod命令加载first.ko这个模块,然后再加载drv.ko这个模块。但是modprobe就不会存在这个问题,modprobe会分析模块的依赖关系,然后会将所有的依赖模块都加载到内核中,因此modprobe命令相比insmod要智能一些。modprobe 命令主要智能在提供了模块的依赖性分析、错误检查、错误报告等功能,推荐使用modprobe命令来加载驱动。modprobe命令默认会去/lib/modules/目录中查找模块,比如本书使用的Linux kernel 的版本号为4.1.15,因此modprobe命令默认会到/lib/modules/4.1.15这个目录中查找相应的驱动模块,一般自己制作的根文件系统中是不会有这个目录的,所以需要自己手动创建。

驱动模块的卸载使用命令"rmmod”即可,比如要卸载drv.ko,使用如下命令即可:

 也可以使用“modprobe-r”命令卸载驱动,比如要卸载drv.ko,命令如下:

 使用modprobe命令可以卸载掉驱动模块所依赖的其他模块,前提是这些依赖模块已经没有被其他模块所使用,否则就不能使用modprobe来卸载驱动模块。所以对于模块的卸载,还是推荐使用rmmod命令。

对于字符设备驱动而言,当驱动模块加载成功以后需要注册字符设备,同样,卸载驱动模块的时候也需要注销掉字符设备。字符设备的注册和注销函数原型如下所示:

 register_chrdev函数用于注册字符设备,此函数一共有三个参数,这三个参数的含义如下:

major:主设备号, Linux下每个设备都有一个设备号,设备号分为主设备号和次设备号两部分,关于设备号后面会详细讲解。

name:设备名字,指向一串字符串。

Fops:结构体file_operations类型指针,指向设备的操作函数集合变量。

unregister_chrdev函数用户注销字符设备,此函数有两个参数,这两个参数含义如下:

major:要注销的设备对应的主设备号。

name:要注销的设备对应的设备名。

一般字符设备的注册在驱动模块的入口函数xxx_init中进行,字符设备的注销在驱动模块的出口函数xxx exit中进行。在示例代码40.2.2.1中字符设备的注册和注销,内容如下所示:

 第1行,定义了一个file_operations结构体变量test_fops, test_fops就是设备的操作函数集合,只是此时我们还没有初始化test_fops中的open、release等这些成员变量,所以这个操作函数集合还是空的。

第10行,调用函数register_chrdev注册字符设备,主设备号为200,设备名字为“chrtest",设备操作函数集合就是第1行定义的test_fops。要注意的一点就是,选择没有被使用的主设备号,输入命令"cat /proc/devices"可以查看当前已经被使用掉的设备号,如图所示:

 在图中可以列出当前系统中所有的字符设备和块设备,其中第1列就是设备对应的主设备号。200这个主设备号在我的开发板中并没有被使用,所以我这里就用了200这个主设备号。

第21行,调用函数unregister_chrdev注销主设备号为200 的这个设备。

file_operations结构体就是设备的具体操作函数,在示例代码40.2.2.1中我们定义了file_operations结构体类型的变量test_fops,但是还没对其进行初始化,也就是初始化其中的open、release、read和write等具体的设备操作函数。我们就完成变量test_fops的初始化,设置好针对chrtest设备的操作函数。在初始化test_fops之前我们要分析一下需求,也就是要对chrtest这个设备进行哪些操作,只有确定了需求以后才知道我们应该实现哪些操作函数。假设对chrtest这个设备有如下两个要求:

1.能够对chrtest进行打开和关闭操作

设备打开和关闭是最基本的要求,几乎所有的设备都得提供打开和关闭的功能。因此我们需要实现file_operations中的open和release这两个函数。

2.对chrtest进行读写操作

假设chrtest这个设备控制着一段缓冲区(内存),应用程序需要通过read和write这两个函数对chrtest的缓冲区进行读写操作。所以需要实现file_operations中的read和write这两个函数。

需求很清晰了,修改示例代码40.2.2.1,在其中加入test_fops这个结构体变量的初始化操作,完成以后的内容如下所示:

 在示例代码40.2.3.1中一开始编写了四个函数: chrtest_open、chrtest_read、chrtest_write和chrtest_release。这四个函数就是chrtest设备的open, read,write和release操作函数。第29行~35行初始化test_fops的open, read, write和release这四个成员变量。

最后我们需要在驱动中加入LICENSE信息和作者信息,其中LICENSE是必须添加的,否则的话编译的时候会报错,作者信息可以添加也可以不添加。LICENSE和作者信息的添加使用如下两个函数:

 最后给示例代码40.2.3.1加入LICENSE和作者信息,完成以后的内容如下:

 第62行, LICENSE采用GPL协议。

第63行,添加作者名字。

至此,字符设备驱动开发的完整步骤就讲解完了,而且也编写好了一个完整的字符设备驱动模板,以后字符设备驱动开发都可以在此模板上进行。

为了方便管理, Linux中每个设备都有一个设备号,设备号由主设备号和次设备号两部分组成,主设备号表示某一个具体的驱动,次设备号表示使用这个驱动的各个设备。Linux提供了一个名为dev t的数据类型表示设备号,dev t定义在文件include/linux/tvpes.h里面,定义如下:

 可以看出dev_t是_u32类型的,而_u32定义在文件

include/uapi/asm-generic/int-1164.h里面,定义如下:

 综上所述, dev_t其实就是unsigned int类型,是一个32位的数据类型。这32位的数据构成了主设备号和次设备号两部分,其中高12位为主设备号,低20位为次设备号。因此Linux·系统中主设备号范围为0-4095,所以大家在选择主设备号的时候一定不要超过这个范围。在文件include/linux/kdev_t.h中提供了几个关于设备号的操作函数(本质是宏),如下所示:

 第6行,宏MINORBITS表示次设备号位数,一共是 20 位。

第7行,宏MINORMASK表示次设备号掩码。

第9行,宏MAJOR用于从dev_t中获取主设备号,将dev_t右移20位即可。

第10行,宏MINOR用于从 dev_t 中获取次设备号,取dev_t的低20位的值即可。

第11行,宏MKDEV用于将给定的主设备号和次设备号的值组合成dev_t类型的设备号。

1.静态分配设备号

设备号分配主要是主设备号的分配。前面字符设备驱动的时候说过了,注册字符设备的时候需要给设备指定一个设备号,这个设备号可以是驱动开发者静态的指定一个设备号,比如选择200这个主设备号。有一些常用的设备号已经被Linux内核开发者给分配掉了,具体分配的内容可以查看文档Documentation/devices.txt并不是说内核开发者已经分配掉的主设备号我们就不能用了,具体能不能用还得看我们的硬件平台运行过程中有没有使用这个主设备号,使用“cat/proc/devices”命令即可查看当前系统中所有已经使用了的设备号。

2.动态分配设备号

静态分配设备号需要我们检查当前系统中所有被使用了的设备号,然后挑选一个没有使用的。而且静态分配设备号很容易带来冲突问题, Linux社区推荐使用动态分配设备号,在注册字符设备之前先申请一个设备号,系统会自动给你一个没有被使用的设备号,这样就避免了冲突。卸载驱动的时候释放掉这个设备号即可,设备号的申请函数如下

 函数alloc_chrdev_region用于申请设备号,此函数有4个参数:

Dev:保存申请到的设备号。

baseminor:次设备号起始地址, alloc_chrdev_region可以申请一段连续的多个设备号,这些设备号的主设备号一样,但是次设备号不同,次设备号以baseminor为起始地址地址开始递增。一般baseminor为0,也就是说次设备号从0开始。

Count:要申请的设备号数量。

name:设备名字。

注销字符设备之后要释放掉设备号,设备号释放函数如下:

此函数有两个参数:

From:要释放的设备号。

count:表示从from开始,要释放的设备号数量。

就以chrdevbase这个虚拟设备为例,完整的编写一个字符设备驱动模块。chrdevbase不是实际存在的一个设备,为了方便讲解字符设备的开发而引入的一个虚拟设备。chrdevbase设备有两个缓冲区,一个为读缓冲区,一个为写缓冲区,这两个缓冲区的大小都为100字节。在应用程序中可以向chrdevbase设备的写缓冲区中写入数据,从读缓冲区中读取数据。chrdevbase这个虚拟设备的功能很简单,但是它包含了字符设备的最基本功能。

在Ubuntu中创建一个目录用来存放Linux驱动程序,比如我创建了一个名为Linux_Drivers的目录来存放所有的Linux驱动。在Linux_Drivers目录下新建一个名为1_chrdevbase的子目录来存放本实验所有文件,如图所示:

 在1_chrdevbase目录中新建VSCode工程,并且新建chrdevbase.c文件,完成以后1 chrdevbase目录中的文件如图所示:

因为是编写Linux驱动,因此会用到Linux源码中的函数。我们需要在VSCode中添加Linux源码中的头文件路径。打开VSCode,按下"Crtl+Shift+P”打开VSCode的控制台,然后输入"C/C++: Edit configurations(JSON) ”,打开 C/C++编辑配置文件,如图所示:

 打开以后会自动在.vscode目录下生成一个名为c_cpp_properties.json的文件,此文件默认内容如下所示:

 第5行的 includePath表示头文件路径,需要将Linux源码里面的头文件路径添加进来,也就是我们前面移植的Linux源码中的头文件路径。添加头文件路径以后的c_cpp_properties.json的文件内容如下所示:

 第7-9行就是添加好的Linux头文件路径。分别是开发板所使用的Linux源码下的include、arch/arm/include和arch/arm/include/generated这三个目录的路径,注意,这里使用了绝对路径。

工程建立好以后就可以开始编写驱动程序了,新建chrdevbase.c,然后在里面输入如下内容:

 第32-36行,chrdevbase_open函数,当应用程序调用open 函数的时候此函数就会调用,本例程中我们没有做任何工作,只是输出一串字符,用于调试。这里使用了printk来输出信息,而不是 printf！因为在Linux内核中没有printf这个函数。printk相当于printf 的孪生兄妹,printf运行在用户态,printk运行在内核态。在内核中想要向控制台输出或显示一些内容,必须使用printk这个函数。不同之处在于,printk可以根据日志级别对消息进行分类,一共有8个消息级别,这8个消息级别定义在文件include/linux/kern levels.h里面,定义如下:

 一共定义了8个级别,其中0的优先级最高, 7的优先级最低。如果要设置消息级别,参考如下示例:

 上述代码就是设置“gsmi: Log Shutdown Reason\n”这行消息的级别为KERN_EMERG。在具体的消息前面加上KERN_EMERG就可以将这条消息的级别设置为KERN_EMERG。如果使用 printk的时候不显式的设置消息级别,那么printk将会采用默认级别MESSAGE_LOGLEVEL_DEFAULT, MESSAGE_LOGLEVEL_DEFAULT默认为4。

在 include/linux/printk.h中有个宏CONSOLE_LOGLEVEL_DEFAULT,定义如下:

 CONSOLE_LOGLEVEL_DEFAULT控制着哪些级别的消息可以显示在控制台上,此宏默认为7,意味着只有优先级高于7的消息才能显示在控制台上。

这个就是 printk和printf的最大区别,可以通过消息级别来决定哪些消息可以显示在控制台上。默认消息级别为4,4的级别比7高,所示直接使用printk输出的信息是可以显示在控制台上的。

参数filp有个叫做private_data的成员变量, private_data是个void指针,一般在驱动中将private_data指向设备结构体,设备结构体会存放设备的一些属性。

第46-61行, chrdevbase_read函数,应用程序调用read函数从设备中读取数据的时候此函数会执行。参数buf是用户空间的内存,读取到的数据存储在buf中,参数cnt是要读取的字节数,参数offt是相对于文件首地址的偏移。kerneldata里面保存着用户空间要读取的数据。

第51行先将kerneldata数组中的数据拷贝到读缓冲区readbuf 中。

第52行通过函数copy_to_user将readbuf中的数据复制到参数buf中。因为内核空间不能直接操作用户空间的内存,因此需要借助copy_to_user函数来完成内核空间的数据到用户空间的复制。copy_to_user函数原型如下:

 参数to表示目的,参数from表示源,参数n表示要复制的数据长度。如果复制成功,返回值为0,如果复制失败则返回负数。

第71~84行,chrdevbase_write函数,应用程序调用write函数向设备写数据的时候此函数就会执行。参数buf就是应用程序要写入设备的数据,也是用户空间的内存,参数cnt是要写入的数据长度,参数offt是相对文件首地址的偏移。

第75行通过函数copy_from_user将buf中的数据复制到写缓冲区writebuf中,因为用户空间内存不能直接访问内核空间的内存,所以需要借助函数copy_from_user将用户空间的数据复制到writebuf这个内核空间中。

第91~95行, chrdevbase-release函数,应用程序调用close关闭设备文件的时候此函数会·执行,一般会在此函数里面执行一些释放操作。如果在open函数中设置了filp的private_data成员变量指向设备结构体,那么在release函数最终就要释放掉。

第100-106行,新建chrdevbase的设备文件操作结构体chrdevbase-fops,初始化chrdevbase_fops。

第113~124行,驱动入口函数chrdevbase_init。

第118行调用函数register_chrdev来注册字符设备。

第131-136行,驱动出口函数chrdevbase_exit,

第134行调用函数unregister_chrdev来注销字符设备。

第141~142行,通过module_init和module_exit这两个函数来指定驱动的入口和出口函数。

第147~148行,添加LICENSE和作者信息。

编写测试APP就是编写Linux应用,需要用到C库里面和文件操作有关的一些函数,比如open、read、write和close这四个函数。

open函数

 open函数参数含义如下:

Pathname:要打开的设备或者文件名。

Flags:文件打开模式,以下三种模式必选其一:

O RDONLY只读模式

O_WRONLY只写模式

O_RDWR读写模式

因为我们要对chrdevbase这个设备进行读写操作,所以选择O_RDWR。除了上述三种模式以外还有其他的可选模式,通过逻辑或来选择多种模式:

O_APPEND每次写操作都写入文件的末尾

O_CREAT如果指定文件不存在,则创建这个文件

O_EXCL 如果要创建的文件已存在,则返回-1,并且修改errno的值

O TRUNCO_NOCTTY如果文件存在,并且以只写/读写方式打开,则清空文件全部内容如果路径名指向终端设备,不要把这个设备用作控制终端。

O_NONBLOCK如果路径名指向FIFO/块文件/字符文件,则把文件的打开和后继I/0 设置为非阻塞

DSYNC等待物理I/O结束后再write。在不影响读取新写入的数据的前提下,不等待文件属性更新。

O_RSYNC read等待所有写入同一区域的写操作完成后再进行。

O_SYNC等待物理I/O结束后再write,包括更新文件属性的I/O。

read函数

 read函数参数含义如下:

Fd:要读取的文件描述符,读取文件之前要先用open函数打开文件,open函数打开文件成功以后会得到文件描述符。

Buf:数据读取到buf中。

count:要读取的数据长度,也就是字节数。

write函数

 write函数参数含义如下:

fd:要进行写操作的文件描述符,写文件之前要先用open函数打开文件, open函数打开文,件成功以后会得到文件描述符。

Buf:要写入的数据。

Count:要写入的数据长度,也就是字节数。

驱动编写好以后是需要测试的,一般编写一个简单的测试APP,测试APP运行在用户空间。测试APP很简单通过输入相应的指令来对chrdevbase设备执行读或者写操作。在1_chrdevbase目录中新建chrdevbaseApp.c文件,在此文件中输入如下内容:

 第21行,数组usrdata是测试APP要向chrdevbase设备写入的数据。

第35行,判断运行测试APP的时候输入的参数是不是为3个,main函数的argc参数表示参数数量, argv[]保存着具体的参数,如果参数不为3个的话就表示测试APP用法错误。比如,现在要从chrdevbase设备中读取数据,需要输入如下命令:

 上述命令一共有三个参数"/chrdevbaseApp"、"/dev/chrdevbase"和“1",这三个参数分别对应 argv[0]、argv[1]和argv[2]。第一个参数表示运行chrdevbaseAPP这个软件,第二个参数表示测试APP要打开/dev/chrdevbase这个设备。第三个参数就是要执行的操作,1表示从chrdevbase中读取数据, 2表示向chrdevbase写数据。

第40行,获取要打开的设备文件名字, argv[1]保存着设备名字。

第43行,调用C库中的open函数打开设备文件: /dev/chrdevbase

第49行,判断argv[2]参数的值是1还是2,因为输入命令的时候其参数都是字符串格式的,因此需要借助atoi函数将字符串格式的数字转换为真实的数字。

第50行,当argv[2]为1的时候表示要从chrdevbase设备中读取数据,一共读取50字节的数据,读取到的数据保存在readbuf中,读取成功以后就在终端上打印出读取到的数据。

第59行,当argv[2]为2的时候表示要向chrdevbase设备写数据。

第69行,对chrdevbase设备操作完成以后就关闭设备。chrdevbaseApp.c内容还是很简单的,就是最普通的文件打开、关闭和读写操作。

首先编译驱动程序,也就是chrdevbase.c这个文件,需要将其编译为.ko 模块,创建Makefile 文件,然后在其中输入如下内容:

第1行, KERNELDIR表示开发板所使用的Linux内核源码目录,使用绝对路径,大家根据自己的实际情况填写即可。

第2行, CURRENT-PATH表示当前路径,直接通过运行"pwd”命令来获取当前所处路径。

第3行, obj-m表示将chrdevbase.c这个文件编译为chrdevbase.ko模块。

第8行,具体的编译命令,后面的modules表示编译模块,-C表示将当前的工作目录切换到指定目录中,也就是KERNERLDIR目录。M表示模块源码目录, "make modules"命令中加入M-dir以后程序会自动到指定的dir目录中读取模块的源码并将其编译为.ko文件。

Makefile编写好以后输入"make”命令编译驱动模块,编译过程如图所示:

 编译成功以后就会生成一个叫做chrdevbaes.ko的文件,此文件就是chrdevbase设备的驱动模块。至此, chrdevbase设备的驱动就编译成功。

测试APP比较简单,只有一个文件,因此就不需要编写Makefile了,直接输入命令编译。因为测试APP是要在ARM开发板上运行的,所以需要使用arm-linux-gnueabihf-gcc来编译,输入如下命令:

 编译完成以后会生成一个叫做chrdevbaseApp的可执行程序,输入如下命令查看chrdevbaseAPP这个程序的文件信息:

 从图可以看出, chrdevbaseAPP这个可执行文件是32位LSB格式, ARM版本的,因此chrdevbaseAPP只能在ARM芯片下运行。

驱动模块chrdevbase.ko和测试软件chrdevbaseAPP都已经准备好了,接下来就是运行测试。为了方便测试, Linux系统选择通过TFTP从网络启动,并且使用NFS挂载网络根文件系统，确保uboot中bootemd环境变量的值为:

 bootargs环境变量的值为:

 设置好以后启动Linux系统,检查开发板根文件系统中有没有"/ib/modules/4.1.15"这个目录,如果没有的话自行创建。注意, "/lib/modules/4.1.15”这个目录用来存放驱动模块,使用modprobe命令加载驱动模块的时候,驱动模块要存放在此目录下。"/lib/modules”是通用的,不管你用的什么板子、什么内核,这部分是一样的。不一样的是后面的“4.1.15”,这里要根据你所使用的Linux内核版本来设置,比如ALPHA开发板现在用的是4.1.15 版本的Linux内核,因此就是"/lib/modules/4.1.15"。如果你使用的其他版本内核,比如5.14.31,那么就应该创建"/lib/modules/5.14.31"目录,否则modprobe命令无法加载驱动模块。

因为是通过NFS将Ubuntu中的rootfs(第三十八章制作好的根文件系统)目录挂载为根文件系统,所以可以很方便的将chrdevbase.ko和chrdevbaseAPP复制到rootfs/lib/modules/4.1.15目录中,命令如下:

 拷贝完成以后就会在开发板的/lib/modules/4.1.15目录下存在chrdevbase.ko和chrdevbaseAPP这两个文件,如图所示:

 输入如下命令加载 chrdevbase.ko驱动文件:

 或

 如果使用modprobe加载驱动的话,可能会出现如图所示的提示:

 从图可以看出, modprobe提示无法打开"modules.dep”这个文件,因此驱动挂载失败了。不用手动创建modules.dep这个文件,直接输入depmod命令即可自动生成modules.dep,有些根文件系统可能没有depmod这个命令,如果没有这个命令就只能重新配置busybox,使能此命令,然后重新编译busybox。输入“depmod”命令以后会自动生成modules.alias、modules.symbols和modules.dep这三个文件,如图所示:

重新使用modprobe加载chrdevbase.ko,结果如图所示: 

 从图可以看到"chrdevbase init!"这一行,这一行正是chrdevbase.c中模块入口函数 chrdevbase_init 输出的信息,说明模块加载成功!

 从图可以看出,当前系统只有"chrdevbase”这一个模块。输入如下命令查看当前系统中有没有chrdevbase这个设备:

从图可以看出,当前系统存在chrdevbase这个设备,主设备号为200,跟我们设置的主设备号一致。 

驱动加载成功需要在/dev目录下创建一个与之对应的设备节点文件,应用程序就是通过操作这个设备节点文件来完成对具体设备的操作。输入如下命令创建/dev/chrdevbase这个设备节点文件: 

 其中"mknod”是创建节点命令, "/dev/chrdevbase”是要创建的节点文件, "c"表示这是个·字符设备,“200”是设备的主设备号,“0”是设备的次设备号。创建完成以后就会存在/dev/chrdevbase这个文件,可以使用"ls/dev/chrdevbase-l"命令查看,结果如图所示:

 如果chrdevbaseAPP想要读写chrdevbase设备,直接对/dev/chrdevbase进行读写操作即可。相当于/dev/chrdevbase这个文件是chrdevbase设备在用户空间中的实现。前面一直说Linux下一切皆文件,包括设备也是文件,现在大家应该是有这个概念了吧?

一切准备就绪,接下来就是“大考”的时刻了。使用chrdevbaseApp软件操作chrdevbase这个设备,看看读写是否正常,首先进行读操作,输入如下命令:

从图可以看出,首先输出“kernel senddata ok!”这一行信息,这是驱动程序中chrdevbase_read函数输出的信息,因为chrdevbaseAPP使用read函数从chrdevbase设备读取数据,因此 chrdevbase_read函数就会执行。chrdevbase_read函数向chrdevbaseAPP发送"kerneldata!" 数据,chrdevbaseAPP接收到以后就打印出来, "read data:kernel data! "就是chrdevbaseAPP打印出来的接收到的数据。说明对chrdevbase的读操作正常,接下来测试对chrdevbase设备的写操作,输入如下命令: 

 只有一行"kemel recevdata:usr data!”,这个是驱动程序中的chrdevbase_write函数输出的。chrdevbaseAPP使用write函数向chrdevbase设备写入数据"usr data!"。chrdevbase-write函数接收到以后将其打印出来。说明对chrdevbase的写操作正常,既然读写都没问题,说明我们编写的chrdevbase驱动是没有问题的。

如果不再使用某个设备的话可以将其驱动卸载掉,比如输入如下命令卸载掉chrdevbase这个设备:

 卸载以后使用Ismod命令查看chrdevbase这个模块还存不存在,结果如图所示:

 从图可以看出,此时系统已经没有任何模块了,chrdevbase这个模块也不存在了,说明模块卸载成功。至此,chrdevbase这个设备的整个驱动就验证完成了,驱动工作正常。